HSDPA provides high speed downlink access from an UMTS base station (Node B) to a plurality of user entities by flexible allocation of downlink resources.
In prior art document WO2005/034418 FIG. 3 and FIG. 5, the protocol layers involved in the communication between user entity (e.g. mobile station), Node B (base station), and RNC (implemented by parts CRNC, and SRNC) have been shown. The user entity involves the following layers: PHY (physical layer), MAC-hs (HSDPA Media Access Control layer), MAC_d (Medium Access Control Device) and a RLC (Radio Link Control layer). Node B communicates via the MAC-hs layer with the user entity and via a frame protocol HS_DSCH-FP with the RNC, respectively.
According to the HSDPA specifications, the RLC operates above the MAC-hs protocol in the protocol stack. The RLC layer provides the connection to upper communication layers such as TCP/IP, both in the user entity and in the RNC. Both the RLC protocol and the MAC-hs protocol are ARQ (Automatic Repeat Request) protocols featuring retransmissions of incorrectly received protocol data units.
As the name implies, the High Speed Downlink Packet Access (HSDPA) technology introduced in 3GPP provides substantial data capacity advantages. The technical specification 3GPP TS 25.321 concerns the MAC (Media Access Control) architecture and the various entities from a functional point of view. 3GPP 25.211 basically describes how information from the MAC-layers is mapped onto the channels transmitted on the air.
In contrast with release 99 (GSM/EDGE) which exclusively defines channels between the RNC and the UE, HSDPA introduced the HS-DSCH (High Speed Dedicated Shared Channel) channel which are terminated between the user entity and the base station set (NODE B), also denoted Node B. The HSDPA Medium Access Control (MAC-hs) enables increased packet data throughput due to link adaptation (Adaptive Modulation Coding—e.g. QAM or QPSK) and fast physical layer retransmission combining. Hence, besides incorporating the WCDMA access technology, Node B carries out scheduling and Hybrid Automatic Repeat Request (HARQ) retransmissions on the channel between the user entity and Node B. The benefits and the features of the above system have for instance been described in “WCDMA evolved—High Speed packet data services”, by Stefan Parkwall et al., Ericsson review No. 2, 2003.
The RLC Layer
As explained in WO2008/007170, the RLC layer in 3GPP can operate in three modes, transparent mode, unacknowledged mode and acknowledged mode (AM), which will be focused upon in the following.
In AM mode, incorrectly received PDU's (Protocol Data Units) discovered by the receiving side are effected to be retransmitted by the transmitting side by means of an ARQ (Automatic Repeat Request) protocol.
An AM RLC entity consists of a transmitting side, and a receiving side, where the transmitting side of the AM RLC entity transmits RLC PDU's and the receiving side of the AM RLC entity receives RLC PDU's.
An AM RLC entity resides in the UE (user equipment) and in the RNC (radio network control), respectively. The transmitting side segments RLC SDU's (service data units) into PDU's of a fixed length. The receiving side reassembles received PDU's into RLC SDU's and transmits these to higher data layers. Likewise, SDU's are received from the layer above the RLC layer. In AM mode, the RLC layer is responsible for the delivery of SDU's in-sequence order.
To facilitate the in-sequence delivery, each RLC PDU is given a sequence number, 0-4095, whereby the transmitter transmits PDU's with increasing sequence number modulo 4096. Using the sequence number, the receiver can detect a missing PDU. The receiver can be configured to transmit a STATUS message upon the detection of a missing PDU. The STATUS report may contain positive or negative acknowledgement of individual RLC PDU's received by the peer RLC entity. The transmitter can also request a STATUS messages from the receiver by setting a Poll flag in the PDU header. The conditions for the transmitter to set the Poll flag are among others:                Last PDU in buffer.        
When only one PDU exists in the input buffer.                Poll timer expires.        
When the timer_poll expires, that is, the transmitter requested a STATUS earlier and initiated a timer_poll to reassure that a response will be received.                Window based.        
A transmitter is restricted in the amount of “outstanding data” it can transmit until a STATUS confirms the reception to the receiving side. “Outstanding data” relates to the earliest unacknowledged PDU.
Note that the above description of the functionality of the RLC layer only constitutes a small excerpt of those features actually provided.
Selective retransmissions are possible, e.g. if STATUS message indicates PDU with sequence number (SN) 3, 6 and 13 are missing, only 3, 6 and 13 needs to be retransmitted.
MAC-hs Layer
In the following exemplary description regarding the MAC-hs layer:                the MAC-hs transmitter is the Node-B.        the MAC-hs receiver is the UE equipment being either a mobile station or a pc-card attached to a PC or any other equipment capable of receiving downlink 3GPP HSDPA traffic.        
MAC-hs PDU's are numbered by modulo TSN (Transport Sequence Number) cycling through the field 0 to 63.
As mentioned above, the MAC-hs protocol provides multiple Hybrid-ARQ processes (HARQ) whereby for each HARQ process, the transmitter transmits a MAC-hs PDU and awaits either an ACK indicative of reception at the receiver or Negative Acknowledgement (NACK) indicative that the receiver did not receive the MAC-hs PDU or absence of a response (DTX). The round trip time, concerning the time from MAC-hs PDU transmission until reception of the feedback (ACK/NACK), is fixed. Upon the reception of a NACK or DTX, the MAC-hs transmitter retransmits the MAC-hs PDU. Since the round trip time is long in relation to the MAC-HS TTI (transmission time interval), i.e. 2 ms, and since multiple users may be adapted to receive packets in time multiplexed fashion, multiple HARQ processes are provided. If only one HARQ process was available, the duty cycle (i.e. actual transmission time/total possible transmission time) would be low. By using multiple HARQ processes, one HARQ process can await a response, while another HARQ process, or multiple HARQ processes, may transmit. Thereby, the duty cycle can be rendered close to 100 percent.
The MAC-hs protocol is semi-reliable, that is, the MAC-hs transmitter may choose to discard or delete a MAC-hs PDU that has been transmitted and possibly been retransmitted to the MAC-hs receiver.
By discarding a MAC-hs for retransmission, unnecessary transmissions are prevented over the radio link in case the MAC-hs receiver has moved to another cell or has powered down or if the receiver for any other reason is not capable of receiving data. Therefore, buffered packets are discarded at the transmitter either at the expiry of a timer set at a predetermined time (e.g. T1) corresponding to the first transmission of the packet in question or when a maximum number of retransmissions of the packet in question have been performed or based upon a too long waiting time in the input data buffer, whatever appears first or a combination thereof.
The MAC-hs receiver utilizes a receiver window for the purpose of mitigating the effect of unnecessary transmissions when PDU's are received in non-ascending sequence order (which can occur due to retransmissions). Whenever a MAC-hs PDU is successfully received with a TSN (Transmit Sequence Number) equal to the next expected TSN, the receiver can deliver the PDU to the RLC layer. Depending on whether the subsequent TSN number (i.e. next expected TSN+1) has already been successfully received, that MAC-hs PDU can also be delivered and so forth. The receiver window is updated accordingly. Delivery to the RLC layer from the MAC-hs protocol is done in consecutive order, also denoted in-sequence.
In-sequence delivery is an efficient method which saves the number of handshaking messages (acknowledge signals) being transmitted over a non-perfect channel. Since the method generally attempts to keep synchronism, it is well adapted to non-time critical services, such as web-browsing.
The in-sequence delivery however, may come to a halt; either if transmitted packets are not received or if transmitted acknowledge messages by the receiving entity are not received by the transmitting entity. The latter is generally attempted to be avoided by using stall avoidance procedures, namely I) Timer based stall avoidance: and II) Window based stall avoidance, as well as MAC-hs reset. These procedures have been further explained in WO2008/007170.
Problems with Existing Solutions
In a scenario where 3GPP HSDPA is rolled out, spots will likely exist where no 3GPP HSDPA coverage is available. Examples of such areas are train tunnels and motorway tunnels.
Assume a case where a user entity is receiving data via HSDPA and that the following situation occurs:                The RNC has outstanding data, meaning that data has been transmitted but not yet acknowledged by the UE, but no pending data to transmit. Assume also that the RNC has a poll_timer active, meaning that the RNC expects that a STATUS message from the UE shall arrive and discover whether or not all outstanding data was correctly received or not.        The Node-B has both outstanding and pending data to transmit, e.g. Node-B has received data from the RNC and is “halfway” in its transmission procedure.        
Assume now that the end user drives in to a tunnel and that radio coverage is lost.
If the time it takes to regain radio coverage is long enough, then the following is assumed to occur:                Node-B will discard all its outstanding data plus pending data after numerous retransmissions. TSN will increase as for successful MAC-hs transmissions despite the absence of feedback from the UE.        
Node-B will after this occasion not perform any retransmissions.                The poll_timer in the RNC will expire. This triggers a retransmission of e.g. last PDU sent. The poll_timer will be restarted.        
Data will be received at Node-B, which will schedule new MAC-hs transmission(s) and succeeding retransmissions. Data will however be discarded since no radio coverage exists with the UE.                At the MAC-hs UE side the T1 timer may have been started which at expiration will deliver data to RLC layer, that may trigger a transmission of a STATUS message. We assume here that the transmission of such a message fails due to the lost radio coverage, but a success will not change the behavior below. It is noted that under certain channel conditions a mixture of the above events may occur.        
The 2 last bullets will be executed again until radio coverage is regained . . . which we assume now . . . and the following occurs:                Node-B has success with its transmission and data will be processed by UE reordering entity.        
Dependent on whether the received TSN is outside the receiver window, three scenarios, illustrated in FIG. 1, in which next expected TSN=57 and highest received HR=1, (receiver window RECW=32), may occur:    Scenario A) The incoming PDU in the MAC-hs user entity is outside the receiver window (TSN=2 . . . TSN=33):            The receiver window will be updated and a T1 timer may be started if TSN < > next_expected_tsn. At expiration of the T1 timer or immediately if TSN=next_expected_tsn MAC-hs, data will be delivered to RLC layer.        The RLC layer at the UE will discover the Poll flag in the RNC PDU, and detect the presence of lost RNC PDUs. A STATUS message will be sent to RNC.        The RNC will detect the STATUS message indicating the reception failure of numerous RNC PDUs. A retransmission of these will occur and the poll_timer will be restarted. If these retransmissions have success we have now corrected the erroneous condition caused by the lost radio access.            Scenario B) The TSN is within receiver window and >=next_expected_tsn (TSN=57 . . . TSN=1):            The scenario is similar to scenario A except that the receiver window will be unchanged.            Scenario C) The TSN is within receiver window and <next_expected_tsn (TSN=34 . . . TSN=56) (Worst case scenario)            Data will be discarded by MAC-hs        The Poll_timer at RNC will expire and a new retransmission will occur.        
In most cases when the time to regain radio coverage is much longer than the T1 timer in the UE, Scenario B will not occur since the T1 timer would have expired such that the following possible scenario, shown in FIG. 1a occurs.
It can be seen here that the time it takes for the RNC to understand that PDUs have been lost, depends on the poll_timer interval, the T1 recovery time at the UE and whether or not the TSN is within receiver window. In scenario C above, it may as a worst case take receive_window_size*poll_timer until lost data is discovered by the RLC layer. We can conclude that it may take long time.